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ROBERT BOSCH GMBH, 70442 Stuttgart 



Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 
Stand der Technik 

Die Erfindung betrifft ein Verfahren und Vorrichtung fur einen fahrzeugbezogenen 
Telematikdienst wie das Einwirken auf wenigstens eine Funktionalitat in einemFahrzeug 
iiber eine Luftschnittstelle, z.B. ein Mobilfunknetz, insbesondere in Verbindung mit der 
Ferndiagnose von Kraftfahrzeugen. 

Die zunehmende Vernetzung von Steuergeraten in heutigen Kraftfahrzeugen bietet immer 
bessere Einwirkungsmoglichkeiten auf Funktionalitaten im Kraftfahrzeug, z.B. bessere 
Diagnosemoglichkeiten im Fehlerfall oder M6glichkeiten zur Fernbedienung von 
Funktionen und/oder Komponenten des Fahrzeugs. In diesem Zusammenhang bestehen 
Konzepte, mit Hilfe eines mobilfunkgestiitzten Einwirkens zuverlassig und sicher auf die 
Funktionalitat im Fahrzeug uber beliebige Entfernungen hinweg zuzugreifen, 
beispielsweise iiber eine Ferndiagnose zuverlassige und qualitativ hochwertige 
Fehleranalysen durch ein Service-Center bzw. einen Ferndiagnose-Server, der eine 
entsprechende Diagnose-Datenbank umfasst, durchzufuhren. GemaB diesen Ansatzen 
werden im Fahrzeug integrierte Kornmunikationssysteme wie beispielsweise 
Mobiltelefone und/oder GSM-gestutzte Telematikendgerate genutzt, um eine 
Dateniibertragung zwischen den an ein Fahrzeugnetzwerk angeschlossenen Steuergeraten 
und/oder Komponenten und dem Server des Service-Centers durchzufuhren. Einen 
Vorschlag fiir ein derartiges System beschreibt die DE 100 26 754 Al. Eine konkrete 
Realisierung hinsichtlich der Obertragungsinhalte zwischen Server und Endgerat sowie 
hinsichtlich der Ausgestaltung von Endgerat bzw. Server werden nicht angegeben. 

Vorteile der Erfindung 




Durch die Aufteilung der Funktionen, z.B. Diagnosefunktionen, zwischen Endgerat und 
Server (Partitionieren von Teilfunktionen) wird eine erhebliche Ressourcenersparnis im 
Fahrzeugendgerat erreicht. Besonders vorteilhaft ist, dass zeitunkritische, 
fahrzeiigspezifische Funktionen, mit denen das Einwirken auf die ausgewahlte 
Funktionalitat gesteuert wird, nicht im Fahrzeugendgerat, sondern im Server vorgehalten 
werden und von diesem iiber die Luftschnittstelle ubertragen werden. Dadurch wird 
vermieden, dass ein zus&tzliches, speziell auf die Anwendung insbesondere hinsichtlich 
vom Fahrzeugnetzwerk vorgegebenen zeitlichen Randbedingungen zugeschnittenes 
Applikations-Protokoll fur die Luftschnittstelle notwendig ist, so dass auf iibliche 
Standard-Protokolle fur die Luftschnittstelle zuruckgegriffen werden kann. Erganzend 
erlaubt die tJbermittlung von fahrzeugspezifischen Informationen iiber die 
Luftschnittstelle eine einheitliche, parametrisierbare Funktionalitat im Endgerat sowie 
eine fahrzeugunabhSngige hnplementierung imEndgerat. Eine besonders hohe 
Flexibility des Systems wird erreicht, die sich auch sich andernde Ausstattungen der 
Fahrzeuge anpassen kann. 

Bei der Ferndiagnose sind Anderungen oder Verbesserungen im Bezug auf die Diagnose 
selbst, sofern diese nicht Onboard in den Steuereinheiten des Fahrzeugs ablaufen, im 
Server moglich. Dies betrifft vor alien den Ablauf und Umfang (iibertragene Daten) des 
Ferndiagnosevorgangs. 



Besondere Vorteile werden in Verbindung mit der Ferndiagnose erreicht, wenn die 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls iiber die Luftschnittstelle 
vom Server zum Endger&t ubertragen werden. 

Durch die Ressourcenersparnis im Fahrzeugendgerat, insbesondere durch die 
Auslagerung zeitunkritischer Vorgange in den Server des Service-Centers wird eine 
einfache und schnelle Umsetzung auf das Fahrzeugnetzwerk imEndgerat moglich. 

Somit ergibt sich insgesamt eine effiziente und vor allem mit geringem Aufwand 
implementierbare Vorgehensweise-zum Einwirken auf eine Fahrzeugfunktionalitat, vor 
allem zur Ferndiagnose, Fernwartung, Fernsteuerung, Software-Download, etc. bei 
Kraftfahrzeugen. 




Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von 
Ausfuhrungsbeispielen bzw. aus den abhangigen Patentanspriichen. 

Zeichnung 

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten 
Ausfiihrungsformen anhand der Ferndiagnose eines Kraftfahrzeugs n&her erlautert. 
Figur 1 zeigt ein Prinzipbild eines Ferndiagnosesystems. 

In Figur 2 ist als tJbersichtsdarstellung die Aufteilung der Diagnosefunktionalitat 
zwischen fahrzeugseitigem und serverseitigem Teil des Systems dargestellt. Insbesondere 
ergeben sich daraus auch Ausgestaltungen des Fahrzeugendgerats bzw. des Servers des 
Service-Centers. 

Figur 3 zeigt ein Ablaufdiagramm, welches den grundsatzlichen Ablauf der Ferndiagnose 
insbesondere im Hinblick auf die Ubertragung zwischen Server und Endgerat sowie im 
Hinblick auf die Funktionen des Endgerats bzw. des Servers in einem bevorzugten 
Ausfuhrungsbeispiel darstellt. 

Figur 4 zeigt die Kommunikation zwischen Server und Endgerat sowie zwischen 
Endgerat und zu diagnostizierendem Steuergerat sowie die in den jeweiligen Einheiten 
ablaufenden Vorgange im Detail anhand eines bevorzugten Ausfuhrungsbeispiels. 



Beschreibung von Ausfuhrungsbeispielen 

Figur 1 zeigt ein tJbersichtsbild eines Systems fur einen fahrzeugbezogenen 
Telematikdienst, wobei Informationen zwischen einem Fahrzeug (dort Endgerat) und 
einem Server liber ein Mobilfunknetz bzw. iiber ein Datennetz, wie beispielsweise das 
Internet, ausgetauscht werden. Eine derartige Konfiguration wird in Verbindung mit 
Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung, Software Download, etc. 
eingesetzt. Unter Fernwirkung bzw. Fernabfrage wird dabei im wesentlichen die 
Fernsteuerung von Fahrzeugfunktionen, insbesondere Komfortfunktionen wie das 
Einschalten der Standheizung, etc., sowie das Abfragen von Fahrzeugstati und/oder 
Betriebsparametern verstanden. Dabei initiiert der Nutzer eine Kommunikation mit dem 
Fahrzeug iiber einen zentralen Server oder er kommuniziert direkt mit dem Fahrzeug. 
Ferndiagnose umfasst das Femauslesen von Diagnosedaten aus dem Fahrzeug, deren 
Analyse und ggf. das Erzeugen einer Empfehlung fur das weitergehende Handeln. 
Analyse der Daten und Generierung der Empfehlung erfolgt dabei durch einen zentralen 
Server, der mit dem Fahrzeug ttber ein Mobilfunknetz, tiber ein drahtgebundenes Netz 
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und/oder uber ein Datennetz wie beispielsweise das Internet mit dem Kraftfahrzeug in 
Verbindung steht. Fenier ist in diesem Zusammenhang als Funktion der sogenannte 
Software-Download bzw. das Remote-Flashing zu nennen, mit deien Hilfe ein neuer 
Programmcode oder Parameter auf per Software konfigurierbare Systeme im Fahrzeug, 
beispielsweise Steuergenite, aufgebracht werden, urn die Funktionalitaten oder die 
Leistungsfahigkeit zu erhohen. Auch hier erfolgt die Kommunikation Uber ein 
MobDfunknetz, ein drahtgebundenes Netz und/oder beispielsweise das Internet 
ausgehend von einem zentralen Rechner (Server) bzw. Service-Center. Femwartung stellt 
im wesentlichen die "Oberwachung des Fahrzeugzustandes und den Zugriff auf die 
Wartungsdaten im Fahrzeug von einer zentralen Stelle aus dar, um zu iibeiprufen, ob, 
wann und welche MaBnahmen zur Wahrung des Sollzustandes durchgefuhrt werden. Ein 
Beispiel hierftir ist das dynamische Anpassen von Wartungsintervallen. Allgemein 
werden diese Funktionalitaten hier unter dem Begriff des fahrzeugbezogenen 
Telematikdienstes subsumiert. 

Figur 1 zeigt einen fahrzeugseitigen Teil 1 sowie einen serverseitigen Teil 2. Beide Teile 
sind uber eine Kommunikationsschnittstelle 3, insbesondere eine Luftschnittstelle, 
beispielsweise uber ein Mobilfiinknetz miteinander verbunden. Der fahrzeugseitige Teil 
besteht aus einem Endgerat 4, beispielsweise einem Telematikendgerat, welches iiber 
eine weitere Schnittstelle 5 mit der Fahrzeugelektronik 6 verbunden ist. Der serverseitige 
Teil 2 besteht aus einem Server 7, welcher beispielsweise von einem Service-Center, dem 
Fahrzeughersteller oder einem Zulieferer betrieben wird, und der uber eine Schnittstelle 8 * 
mit einem Datenspeicher 9 hi Verbindung steht, in dem beispielsweise im Rahmen einer 
Datenbank fahrzeugbezogene Daten und/oder Kommandos und/oder Programme abgelegt 
sind. Wie nachfolgend im Detail beschrieben, werden bei dem dargestellten Client- 
Server-System Teilfunktionen partitioniert, d.h. dem Server und den Client bestimmte 
Funktionalitaten eines Telematikdienstes zugeordnet. Dabei wird von einer vollstandigen 
Vernetzung der zu diagnostizierenden bzw. zu steuernden Steuergerate im Fahrzeug mit 
demEndgerats z.B. durch einen CAN-Bus sowie von der Verfugbarkeit der Schnittstelle 
3, insbesondere einer Mobilfunkschnittstelle im Kraftfahrzeug, ausgegangen. Die 
bekannten, unterschiedhchen Verfahren fur die Erfassung von Diagnosedaten, 
beispielsweise iiber eine CAN-Bus-Schnittstelle, lassen sich in nichtzeitkritische und 
zeitkritische Anwendungen aufteilen. Zu den nichtzeitkritischen Anwendungen gehort 
beispielsweise die Ablaufsteuerung des Diagnose-Testers, mit Zugriff auf eine 
Datenbank, sowie das Diagnose-Protokoll selbst, beispielsweise das Protokoll KWP2000 
bzw. Varianten davon. Zeitkritische Anwendungen sind das Transport-Protokoll des 




Fahrzeugnetzes (z.B. CAN-Transport-Protokoll) oder Varianten davon, dessen 
Kommunikationsschicht (z.B. CAN-KommunikationsscMcht) sowie der Bus (z.B. CAN- 
Bus) selbst Wesentlich ist, dass bei der Implementierung der Telematikfunktion im 
Kraftfahrzeug die zeitkritischen Vorgange gegeniiber dem unsichereren Mobilfunkkanal 
entkoppelt werden. Daher werden alle oder ein Teil der relevanten Funktionen aus dem 
Fahrzeug ausgelagert, bei denen keine engen zeitlichen Anfordenmgen bestehen, 
insbesondere Anforderungen bezugliche einer minimalen oder maximalen Zeitdauer 
zwischen Ko mm ando und Antwort bei einer Dateniibertragung. Im Extremfall bleibt 
daher lediglich der zeitkritische Datentransport auf dem Fahrzeug-Bus (z.B. CAN-Bus 
oder Ahnliches), welcher durch Funktionen des Transport-Protokolls wie beispielsweise 
die Fragmentierung und Defragmentierung komplexer Nachrichten, realisiert ist, auf der 
Client- bzw. Fahrzeugseite zuriick. Der Funktionsumf ang des in der Regel komplexeren 
und fahrzeugspezifischen Dienste-Protokolls (z.B. Diagnoseprotokoll) wird dabei auf 
einen entsprechenden Server (z.B. Diagnoseserver) ausgelagert. Im Anwendungsfall der 
Ferndiagnose werden neben der tfbertragung fahrzeugspezifischer Diagnose-Kommandos 
auf der Basis des jeweils verwendeten Diagnose-Protokolls ferner zusatzliche 
Informationen zwischen der Server-Applikation (Ablaufsteuerung fiir den 
Gesamtvorgang) und der Client- Applikation (Ablaufsteuerung zur Datenerfassung) 
iibertragen. Diese Ablaufsteuerungen dienen der Aktivierung des Diagnosevorgangs, der 
Konfiguration der Client-Applikation und der spateren Ubermittlung von Ergebnissen der 
serverseitigen Datenanalyse. In dem skizzierten Beispiel, bei dem alle zeitunkritischen 
Vorgange aus dem fahrzeugseitigen Teil in den serverseitigen Teil des Systems 
ausgelagert wurden, ergibt sich die in Figur 2 dargestellte Systemarchitektur. In anderen 
Ausfuhrungen wird nur ein Teil der nichtzeitkritischen Vorgange ausgelagert, wahrend 
ein Teil im fahrzeugseitigen Endgerat verbleibt. So ist beispielsweise yorstellbar, dass 
fahrzeugspezifische Daten und/oder spezielle fahrzeugspezifische Diagnose-Kommandos, 
die aus Sicherheitsgriinden nicht ausgelagert werden, im fahrzeugseitigen Teil des 
Systems verbleiben. 

In Verbindung mit anderen Telematikdiensten wie der Fernsteuerung von Komponenten, 
den Softwaredownload, etc. wird auf cFie-gescEilderte Art und Weise zeitunkritische 
Anwendungen ausgelagert, wahrend zeitkritische Anwendungen im Fahrzeugendgerat 
verbleiben. 



In Figur 2 ist das Fahrzeugendgerat (Client) 4 sowie der Server 7 dafgestellt, welche iiber 
eine Luftschnittstelle 3 miteinander verbunden sind. Im bevorzugten Ausflihrungsbeispiel 
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handelt es sich bei der Luftschnittstelle 3 urn ein herkommliches, beispielsweise auf dem 
GSM-Standard basierendes Mobilfunknetz. In anderen Anwendungen handelt es sich urn 
Mobilfunknetze, die mit anderen Standards arbeiten. Der Server umfasst die folgenden 
Module: ein Mobilfunk-Kommuni^ 7a, ein 

Mobaftinkkommiinikation-Modul 7b, ein Ablaufsteuerungs-Modul 7c sowie ein 
fahrzeugspezifisches Diagnose-Protokoll-Modul 7d. Das Fahrzeugendgerat umfasst 
ebenfalls ein Kommunikations-Protokoll-Modul 4a, ein Modul 4b zur Kommunikation 
iiber die Mobilfunkschnittstelle, ein Modul 4c zur CAN-Kommunikation sowie ein 
Transport-Protokoll-Modul 4d. Ferner ist eine Ablaufsteuerung 4e im Fahrzeugendgerat 
vorgesehen. Die Module stellen dabei vorzugsweise Softwareprogramme dar. 

Diese Funktionseinheiten haben die folgenden Aufgaben: 

Die Mobilfunkkommunikations-Module 4b, 7b, die sowohl im Endgerat als auch im 
Server vorgesehenen sind, diesen zur stabilen Dateniibertragung, zum Verbindungsaufbau 
bzw. -abbau, der Datensicherheit, gegebenenfalls der Verschlusselung, Packetierung, 
etc. Diese Aufgaben werden von ublichen Konmimikationsfunktionseinheiten realisiert 
und sind z.B. imRahmen der GSM-Standards verfugbar. 

Das im Fahrzeugendgerat vorgesehene CAN-Kommunikation-Modul 4c stellt eine 
hardwareunabhangige Softwareschnittstelle zur Ubertragung von Daten iiber einen CAN- - 
Bus zu angeschlossenen Steuergeraten dar. Dazu gehoren die Initialisierung und 
Steuerung des CAN-Controllers, die Ubertragung und den Empfang von CAN- 
Bausteinen sowie tJberlauf-Fehlerbehandlungen und Weckfunktionen. Ferner umfasst das 
Modul die Funktionen der OSI-Layer 1 und 2 (Physical Layer, Data Link Layer). Das 
Softwaremodule arbeitet dabei im Rahmen der giiltigen CAN-Spezifikation. In anderen 
Ausfuhrungen wird anstelle des CAN-Bus ein anderes Bussysteme eingesetzt 
(standardisiert oder kundenspezifisch), wobei das Softwarembdul dann auf der Basis 
einer entsprechenden Spezifikation realisiert ist. 

Die Ablaufsteuerung 7c im Server zerlegt die Diagnose-Grundfiinktionen in einzelne 
Teilprozesse bzw. Diagnose-Services, ubernimmt die Initialisierung des Prozesses, 
steuert und beendet den Diagnosevorgang, verarbeitet die erforderlichen Parameter- und 
gegebenenfalls Protokoll-Mechanismen fur den Diagnosevorgang und steuert den 
Gesamtvorgang zeitlich. Ferner werden hier die ermittelten Diagnosedaten ausgewertet, 
gegebenenfalls eine Generierung einer Empfehlung durchgef iihrt. Ferner ubernimmt die 
Ablaufsteuerung den Zugriff auf die Diagnose-Datenbank des Servers. Die 
Ablaufsteuerung stellt ein Software-Modul dar, welches fur die spezielle Anwendung 




konzipiert ist. Bin Beispiel wird nachfolgend anhand der Femdiagnose in den Figuren 3 
und 4 skizziert 

In entsprechender Weise ist ein Ablaufsteuenmgs-Modul 4e im Fahrzeugendgerat 
vorgesehen. Auch dieses Software-Modul ist fiir die spezielle Anwendung konzipiert. Ein 
Beispiel wird nachfolgend anhand der Femdiagnose in den Figuren 3 und 4 skizziert. 
Diese Ablaufsteuerung erzeugt eine Server-Anfrage zur Durchfuhrung einer 
Femdiagnose. Sie konfiguriert die Funktionen im Fahrzeug, beispielsweise durch 
Festlegen einer Tester-Present-Nachricht, Einstellen der Timing-Parameter fiir das 
Transport-Protokoll und gegebenenfalls Einstellen der Parameter fur die CAN- 
Kommunikation. Die Ablaufsteuerung fiihrt ferner die Diagnose-Kommunikation durch 
zyklisches Generierung von Tester-Present-Nachrichten mit den zu diagnostizierenden 
Steuereinheiten durch. Femer werden von ihr die vom Server ubertragenen Diagnose- 
Kommandos auf das CAN-Transport-Protokoll umgesetzt. Daruber hinaus ubertragt das 
Ablaufdiagramm die Daten an den Server und setzt zu diesem Zweck die im Fahreeug 
ennittelten Diagnose-Daten auf die Mobilfunkschnittstelle um. Daruber hinaus sind 
MaBnahmen getroffen, mit denen in einem Ausfuhrungsbeispiel die bewerteten 
Ergebnisse der Fehleranalyse, die vom Server ubermittelt werden, angezeigt werden. 
Femer ubernimmt die Ablaufsteuerung die Beendigung der Diagnose-Kommunikation 
durch Stoppen der Generierung von Tester-Present-Nachrichten. Daruber hinaus wird in 
einem Ausfuhrungsbeispiel das automatische Beenden eines unterbrochenen 
Diagnosevorgangs, z.B. durch Timeout oder Watchdog fur den Empfang von Server- 
Kommandos, durchgefuhrt. 



Das im Client 4 vorgesehene Transport-Protokoll-Modul 4d fuhrt die Ubertragung von 
komplexen Nachrichten oder Dateneinheiten iiber einen CAN-Bus durch, nimmt die 
Entkopplung des Diagnose-Protokolls vom physikalischen tJbertragungsmedium vor und 
stellt die Dienste des OSI-Layers 3 (Network Layer) zur Verfugung, sowie die 
Verbindung zwischen dem OSI-Layer 2 (Data Link Layer) und 7 (Applikation Layer). Es 
werden als also vom Transport-ProtokoU-Modul eine Segmentierung und Erfassung von 
Daten des Data LirikXayers vorgenommen, das heifit die Steuerung des Datenflusses 
einzelner Botschaften inklusive Verwaltung und Zuordnung von physikalischen CAN- 
Botschaften zu logischen Nachrichten oder Dateneinheiten sowie die Fehlererkennung. 
Eine Realisierung stellt das allgemein verbreitete ISO-Transport-Protokoll (ISO 15765-2) 
dar, wobei in anderen Anwendungen auch spezielle Varianten dieses Protokolls 
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eingesetzt werden. Dies gilt auch bei der Verwendung anderer Bussysteme zur 
Kommunikation mit den FahrzeugsteuergerSten. 

Das dem Server zugeordnete Diagnose-Protokoll-Modul 7d umfasst die Diagnoseschicht, 
welche in einer bevorzugten Anwendung das nach ISO spezifizierte Diagnose-Protokoll 
KWP2000 enthalt, wobei je nach AusfUhrungsbeispiel auch Varianten davon eingesetzt 
werden. In diesemDiagnose-Protokoll-Modul sind spezielle Diagnose-Dienste definiert, 
die je nach Kraftfahrzeughersteller und/oder Kraftfahrzeugtyp unterschiedlich genutzt 
werden und zumTeil unterschiedliche Zusatzdienste enthalten. Das Diagnose-Protokoll- 
Modul wertet die Diagnose-Anfragen aus. Weitere Aufgaben, die durch das Modul gelOst 
werden, sind die Konvertierung von Diensten in eine funktionale SchnittsteUe fur die 
Anwendungsschicht, die direkte Nutzung spezieller Dienste und die 
Ausnahmebehandlung bei Nutzung von unbekannten Diensten. Ein Beispiel fur die 
Realisierung eines solchen Modul ist aus den nachfolgend beschriebenen 
Vorgehensweisen entnehmbar. 

Die grundsatzliche Vorgehensweise im Rahmen der Ferndiagnose besteht darin, dass 
nach Aktivierung der Ferndiagnose durch eine Bedienperson, z.B. den Nutzer des 
Kraftfahrzeugs, und/oder den Service-Provider und/oder den Fahrzeughersteller und/oder 
eines Monteurs einer Werkstatt nach Abschluss der Mafinahmen zum Verbindungsaufbau 
zwischen Endgerat und Server die Kommandos des fahrzeugspezifischen Diagnose- 
Protokolls ttber die Luftschnittstelle vom Server zum Endgerat ttbertragen werden. Die 
fahrzeugspezifischen Diagnose-Protokoll-Kommandos werden dabei vom Diagnose- 
Server nach Identifizierung des zu diagnostizierenden Kraftfahrzeugs aus einer 
Datenbank ausgelesen. Das Endgerat setzt die tibertragenen Diagnose-Kommandos auf 
das Fahrzeugnetzwerk um. Die erfolgt beispielsweise dadurch, dass die empfangenen 
Kommandos in Kommandos fur das diagnostizierende Steuergerat umgesetzt werden und 
Uber die SchnittsteUe zum Fahrzeugnetzwerk, insbesondere Uber einen CAN-Bus, an das 
Steuergerat gesendet werden. Die Antwort dieses Steuergerats wird als Datennachricht 
aus dem Fahrzeugnetzwerk im entsprechenden Format Uber die 
Fahrzeugnetzwerkschnittstelle empfangen und wird dann vom Endgerat in 
Antwormachrichten fur den Server umgesetzt. Diese werden dann an die 
Mobilfunkschnittstelle ubermittelt, die die Nachricht liber ein vorgesehenes 
Obertragungs-Protokoll (beispielsweise im Rahmen des GSM-Standards) an den Server 
geschickt wird. Zusammenfassend setzt der Client im bevorzugten AusfUhrungsbeispiel 
also das vom Server ubertragene Diagnose-Protokoll (KWP2000) auf das CAN- 




Transport-Protokoll umund umgekehrt. Die Ablaufsteuerung des beschriebenen 
* Vorgangs zur Aufrechterhaltung der Diagnose-Kommunikation im Fahrzeug erfolgt im 
Endgerat autark, beispielsweise durch sogenannte Tester-Present-Nachrichten. Diese sind 
in der KWP2000-Spezifikation definiert und dienen der ErfLillung der zeitlichen 
Anforderungen der Fahrzeugnetzwerkes. Dadurch wird eine Entkopplung der 
zeitkritischen Diagnose-Kommunikation imFahrzeug von den zeitunkritischen 
Diagnoseablaufen im Server erreicht. Ergebnis ist somit eine flexible Konfiguration der 
fahrzeugspezifischen Diagnose-Kommunikation imFahrzeug, die nicht durch mogliche 
Probleme der Luftschnittstelle und der Diagnoseablaufe im Server belastet ist. 

Hgur 3 zeigt ein Ablaufdiagramm des Gesamtvorgangs, der in fiinf grundlegende 
Teilschritte gegliedert ist. Die detaillierten Ablaufe innerhalb eines solchen Teilvorgangs 
sind je nach Fahrzeugtyp, dem moglicherweise vorliegenden FehlerfaU und/oder der 
jeweiligen Implementierung des Systems im Diagnose-Server variierbar. Im ersten Schritt 
100 erfolgt das Starten der Diagnose mit einer entsprechenden Anfrage an den Server. 
Die Aktivierung erfolgt dabei im bevorzugten Ausfuhrungsbeispiel durch den Fahrer 
bzw. Nutzer des Kraftfahrzeugs der durch Anruf oder Ahnliches beim Service-Center 
eine Aufforderung des Servers an den Client im Fahrzeug erzeugt, eine Diagnose- 
Verbindung aufzubauen. Der Client baut dann die angeforderte Verbindung auf . In 
anderen Ausfuhrungsbeispielen wird die Diagnose-Verbindung durch eine Anfrage vom 
Client aus aufgebaut Der Aufbau der eigentlichen Diagnose-Verbindung erfolgt hier 
durch den Server oder den Client. Im n£chsten Schritt 200 erfolgt die Konfiguration der 
Femdiagnose-Funktionalitat im Fahrzeug durch den Server. Dabei wird die 
Ablaufansteuerung, die Transportschicht und gegebenenfalls die CAN-Kommunikation 
an das spezifische Fahrzeug angepasst. Dies erfolgt durch Kommandos bzw. Daten vom 
Server, die dieser aus einer Datenbank fur das spezielle Fahrzeug bzw. Fahrzeugtyp / 
und/oder Austattungsvariante ausliest. Bei der Aktivierung erhalt der Server 
beispielsweise mittels eines Identifikationscodes Informationen uber das zu 
diagnostizierende Fahrzeug. Anhand dieser Information liest er fahrzeugspezifische 
Parameter aus der Datenbank aus, die er dann an den Client zur Konfiguration der 
Femdiagnose-Funktionalitat ubermittelt. 

Nach den Teilschritten Aktivierung (100) und Initialisierung (200) wird der Teilschritt 
Ausfiihrung des Diagnosevorgangs (301 bis 303) an einem Beispiel eines Steuergerats 
gezeigt. Zunachst wird im Schritt 301 durch den Server im zu diagnostizierenden 
Steuergerat, sofem dies notwendig ist, der Diagnosemode angestoBen, so dass das 
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Steuergerat zum Ausfiihren der Diagnose-Funktion in der Lage ist. Ferner erf olgt die 
Identifikation des Steuergerat, z.B. dessen Softwarestand zur Anpassung der Diagnose- 
Kommandos an den speziellen Steuergeratetyp. Auch dies ist optional und wird dann 
eingesetzt, wenn dies z.B. aufgrund der Vielzahl von Softstanden sich als erforderlich 
erweist. Danach werden die ausgewahlten Diagnose-Kommandos vom Server an den 
Client im Fahrzeug iibertragen. Beispiele fur solche Diagnose-Kommandos sind das 
Auslesen wenigstens eines Fehlerspeichers des betroffenen Steuergerats, das Auslesen 
von gespeicherten Umgebungs-Parameter eines aufgetretenen Fehlers und/oder das 
Abfragen von zusatzlichen Ist-Werten aus dem entsprechenden Steuergerat. 

Im Schritt 302 setzt der Client das oder die ubermittelten Diagnose-Kommandos auf das 
Fahrzeugnetzwerk urn. Im darauf folgenden Schritt 303 wird die Antwort des 
Steuergerats auf das oder die gesendeten Kommandos, welche beispielsweise innerhalb 
einer bestimmten Zeitperiode auftreten muss, empfangen, vom Client uber auf die 
Obertragungsschnittstelle zum Server umgesetzt und an diesen zuriickgesendet. Die 
Schritte 301 bis 303 werden dann flir jedes zu diagnostizierende Steuergerat oder, wenn 
die Diagnosekommandos einzeln nacheinander oder in Gruppen nacheinander versendet 
werden, fur jedes einzelne Diagnose-Kommando oder Diagnose-Kommando-Gruppe 
wiederholt. 1st die Diagnose fur ein Steuergerat beendet, wird als Diagnose-Kommando 
ein Ende-Kommando gesendet, welches ggf. den Diagnose-Mode im Steuergerat 
deaktiviert und dieses wieder in den normalen Betriebsmode zuriickversetzt. 

Der vierte Teilschritt betrifft die Auswertung der erhaltenen Daten im Server (Schritt 
400). Der Server wertet der nach MaBgabe eines ggf. spezifischen Algorithmus die 
gesammelten Fehlerinformationen aus, ermittelt ein Diagnose-Ergebnis und/oder 
Empfehlungen fiir das weitere Vorgehen. Im darauf folgenden Schritt 500 werden dann 
die vom Server ennittelten Ergebnisse an das Endgerat ubertragen urid von diesem im 
Fahrzeug angezeigt. Dieser funfte Teilschritt stelle somit die Ergebnisausgabe dar. Im 
diesem Schritt ist auch in einem Ausfuhrungsbeispiel die tJbermittlung und Anzeige einer 
Empfehlung fur das weitere Vorgehen im Fehlerfall vorgesehen, z.B. „Werkstatt 
aufsuchen", etc. 

Figur 4 zeigt ein beispielhaftes Kommunikationsszenario zwischen einem Ferndiagnose- 
Server, einem Telematikendgerat und einem Steuergerat. Das Kommunikationsszenario 
stallt eine Realisierung des dritten Teilschritt in Figur 3 im Detail dar. Basis der 
Kommunikation ist das nach ISO 14230-3 spezifizierte Diagnose-Protokoll KWP2000. In 
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anderen Ausftthrungsbeispielen werden hersteUerspezifische Varianten dieses Diagnose- 
ProtokoUs oder auch andere Diagnose-Protokolle entsprechend eingesetzt. Je nach 
Ausfiihrungsbeispiel variiert die Abfolge der Schritte und der Umfang der Schritte in den 
einzelnen Anwendungen. Figur 4 zeigt eine bevorzugte Realisierung der Kommunikation 
zwischen einemFemdiagnose-Server I, einem im Fahrzeug angeordneten 
Telematikendgerat II und einem zu diagnostizierenden Steuergerat EL Die 
Kommunikation basiert dabei auf dem Diagnose-Protokoll KWP2000, welches in der 
ISO 14230-3 spezifiziert ist Die Fehlerermittlung und das Setzen der Fehlerspeicher 
erfolgt dabei in den meisten Falle durch bekannte Diagnosemethoden im zu 
diagnostizierenden Steuergerat durch dort vorhandene oder dort eingelesene Software. 

Li Figur 4 sind die einzelnen einer Kommunikation zwischen den drei beteiligten 
Einheiten dargestellt, wobei von oben nach unten eine zeitUche Reihenfolge ausgedruckt 
sein soil. In den Einheiten sind Softwareprogramme vorhanden, die die zu Ubeimittlenden 
Nachrichten erzeugen, auswerten, etc. 

Nach Abschluss der Teilvorgange 1 und 2 (siehe Figur 3, Schritte 100 und 200) wird in 
einem ersten Schritt SI der Diagnose-Mode im zu diagnostizierenden Steuergerat 
aktiviert. Dazu sendet der Server ein entsprechendes Diagnose-Kommando (Start- 
Diagnostic-Session-Request). Dieses wird vom Endgerat empfangen und iiber die 
Schnittstelle zum diagnostizierenden Steuergerat weitergeleitet (Schritt S2) bzw. zuerst in 
ein fur das Fahrzeugnetz geeignetes Format umgesetzt (z.B. mittels einer Tabelle) und 
dann auf das Fahrzeugnetz gegeben. Das zu diagnostizierende Steuergerat antwortet mit 
einer entsprechenden Antwort (Start-Diagnostic-Session-Response), die angibt, ob der 
Diagnose-Mode eingeleitet ist oder nicht. Diese Information sendet das zu 
diagnostizierende Steuergerat im Schritt S3 zum Endgerat, welches wiederum im Schritt 
S4 (ggf. nach Umsetzung auf das vorgesehene Format) die Information zum Server 
iibertragt. 

Daraufhin wird zur Ablaufsteuerung und zur Erfullung der Zeitanforderung im 
Fahrzeugnetz vom Endgerat E zum Steuergerat HI im Schritt S5 eine Kommando 
geschickt (Tester-Present-Request), welches im Schritt S6 von Steuergerat mit einer 
entsprechenden Antwort (Tester-Present-Response) beantwortet wird. Diese 
Kommunikation wird im folgenden wahrend des Diagnosevorgangs dann ausgefiihit, 
wenn vom Server kein anderes Diagnose-Kommando weiterzuleiten ist bzw. vom 
Steuergerat keine Antwort an den Server zu leiten ist. Daher konnen die Schritte S5 und 
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S6 auch mehrfach wiederholt werden, sblange bis das erwartete Kommando vom Server 
eropfangen wird. Tritt eines der genannten Ereignisse nicht auf, wird die Kommunikation 
zrwischen Endgerat und Steuergerat abgebrochen. 

Nach Empfang der Antwort im Schxitt S4 sendet der Server im Schritt S7 ein Kommando 
(Read ECU-Identification-Request), welches die Identification des zu diagnostierenden 
Steuergerats anfragt. Dieses Kommando wird vom Endgerat empfangen und ggf. 
umgesetzt und dann im Schritt S8 zum Steuergerat ubermittelt. Das Steuergerat liest aus 
seinem Speicher daraufhin wenigstens einen Identifikationsparameter aus und sendet 
diesen zum Endgerat (Read ECU-Identification-Response, Schritt S9). Diese Information 
wird dann ggf. nach Umsetzung vom Endgerat II im Schritt S 10 an den Server 
ubertragen. Anhand des Identifikationsparameters erkennt der Server das Steuergerat, 
gegebenenfalls dessen Software-Stand sowie gegebenenfalls das Fahrzeug und wahlt aus 
der Datenbank entsprechende Parameter aus. In der Zwischenzeit lauft, wie anhand der 
Schritte SI 1 und S12 dargestellt, zwischen Endgerat und zu diagnostizierenden 
Steuergerat die oben beschriebene Tester-Present-Kommunikation ab, die sicherstellt, 
dass die Kommunikation zwischen Endgerat und Steuergerat aufrechterhalten bleibt, das 
Steuergerat im Diagnosemode verbleibt und keine Verletzung der Randbedingungen fin- 
die Kommunikation im Fahrzeugsnetz, die zum Abbruch filhrt, erfolgt. 

In den nachsten Schritten werden die Fehlerspeicher des zu diagnostizierenden 
Steuergerats ausgelesen. Dazu Ubermittelt der Server nach Empfang der Nachricht im 
Schritt S10 und Auslesen der steuergeratspezifischen Parameter zum Endgerat im Schritt 
S13 eine entsprechende Anfrage (Read DTC-Request). In dieser Anfrage sind die 
steuergeratspezifischen Parameter enthalten, in denen zJB. angegeben ist, welche 
Fehlerspeicher auszulesen sind. Diese Anfrage wird im Schritt S14 von Endgerat ggf. 
nach Umsetzung zum Steuergerat ubertragen. Das Steuergerat fiihrt die empfangenen 
Kommandos aus und sendet die Fehlerspeicherinhalte als Botschaft Read DTC-Response 
im Schritt S15 zum Endgerat. Die Botschaft Read DTC-Response enthalt demnach die 
relevanten Fehlerspeicherinhalte. Die Antwort wird vom Endgerat ggf. nach Umsetzung 
im Schritt S16 zum Server Ubertragen. Daraufhin wird in den Schritten S17 und S18 die 
oben erwahnte Tester-Present-Kommunikation zwischen Endgerat und Steuergerat bis 
zum emeuten Empfang einer Botschaft vom Server durchgefuhrt. 

Iin darauf folgenden, optionalen Teilschritt werden die zu den Fehlereintragen geherige 
Umgebungsparameter ausgelesen. Zu diesem Zweck sendet der Server nach Empfang der 
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Botschaft im Schritt S16 und nach Auswertung der Fehlereintrage im Schritt S19 an das 
Endgerat eine entsprechende Anfrage (Read-Freeze Frame-Request), die dieses ggf. nach 
Umsetzung im Schritt S20 an das Steuergerat weitergibt. Je nach Ausftihrung liest das 
Steuergerat dann die gewiinschten Parameter zu den gespeicherten Fehlern aus oder der 
Server spezifiziert anhand der Inhalte der Fehlerspeicher den Ihhalt seiner Botschaft, so 
dass mit dieser Botschaft nur bestimmte Umgebungsparameter angefordert werden. Das 
Steuergerat jedenfaUs antwortet mit einer entsprechenden Antwort (Read-Freeze Frame- 
Response), in welchem die auf die eine oder andere Weise angeforderten Parameter 
enthalten sind. Im Schritt S21 wird die Antwort an das Endgerat gesendet, welches die 
Antwort wiederum ggf. nach Umsetzung im Schritt S22 zum Server iibertrag. In den 
Schritten S23 und S24 erfolgt emeut die Tester-Present-Kommunikation. 

Im darauf folgenden Teilschritt, nach dem Fehlerspeicher und zugehorige 
Umgebungsparameter ausgelesen und ubertragen sind, wird der Diagnosemode im 
Steuergerat deaktiviert. Hierzu schickt der Server eine Aufforderung zum Beenden die 
Diagnosevorgangs (Stop-Diagnostic-Session-Request) an das Endgerat. Dieses gibt die 
Aufforderung zumBeenden an das Steuergerat weiter (Schritt S26), welches mit einem 
entsprechenden Antwortsignal (Stop-Diagnostic-Session-Response) im Schritt 27, mit 
welcher das Steuergerat die Beendigung des Diagnose-Modus mitteilt, antwortet. Diese 
Information wird vom Endgerat im Schritt S28 zum Server ubertragen. Daraufhin (Schritt 
S29) werden die oben dargestellten Teilvorgange 4 und 5 beziiglich Auswertung und 
Anzeige der Diagnose-Ergebnisse und ggf. -Empfehlungen weitergefuhrt. 

Das dargestellte Kommumkationsszenario ist ein Beispiel. In anderen Ausfiihrungen 
fehlen die Schritte zum Aktivieren und Deaktivieren des Diagnose-Modes im Steuergerat 
und/oder zur Identifikation des Steuergerats und/oder zum Auslesen der zugehorigen 
Umgebungsparameter. 

Die konkrete technische Realisierung der dargestellten Kommunikation findet durch 
entsprechende Software-Programme in Server, Endgerat und Steuergerat statt, die jedes 
ftir sich ebenfalls Teil der vorliegenden Erfindung sind. 
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Patentanspriiche 

1 . Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise imKraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind, wobei im Server zeitunkritische 
Funktionalitaten, im Endgerat zeitkritische Funktionalitaten ablaufen.. 

2. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in TeUfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

J. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise im 
Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 

. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
die zeitkritischen Teilfunktionalitaten autark im Endgerat ablaufen, die 
zeitunkritischen TeilfunktionaKtaten vom Server mittels Kommunikatioon mit dem 
Endgerat durchgefuhrt werden. 
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5. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
im Endgerat die zeitkritische Kommunikation mit einem zu diagnostizierenden 
Steuergerat und/oder einer zu diagnostizierenden Komponenten implementiert ist. 

6. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
der Telematikdienst eine Ferndiagnose eines Kraftfahrzeugs ist und dass das 
Diagnose-Protokoll im Server implementiert ist 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls iiber eine 
Luftschnittstelle vom Server zum Endgerat iibertragen wird. 

8. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
das Endgerat die tibertragenen Diagnose-Komrnandos auf ein Fahrzeugnetzwerk 
umsetzt und die erzeugten Antwortnachrichten an die Mobilfunkschnittstelle 
iibermittelt. 

9. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
als Diagnose-Protokoll KWP2000 oder eine Variante davon eingesetzt wird. 

10. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server)-und emem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind. 

11. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

12. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise 
im Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 
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13. Vorrichtung nach Anspruch 10 oder 11, wobei der Server iiber eine Luftschnittstelle 
mit dem Endgerat kommuniziert, dadurch gekennzeichnet, dass der Telematikdienst 
eine Ferndiagnose eines Kraftfahrzeugs ist, wobei das Diagnose-Protokoll als 
zeitunkritische Teilfunktionalitat im Server implementiert ist. 

14. Vorrichtung nach Anspruch 10 oder 12, wobei das Endgerat iiber eine 
Luftschnittstelle mit dem Server kommuniziert und welches eine weitere Schnittstelle 
umfasst, mit dem es mit einer zu diagnostizierenden Einheit verbunden ist, dadurch 
gekennzeichnet, dass das Endgerat als zeitkritische Teilfunktionalitat eine 
Ablaufsteuerung umfasst, die autark gegeniiber der zentralen Recheneinheit ist und 
die die Diagnose-Kommunikation im Fahrzeug aufrecht erhalt. 

15. Computerprogramm mit Programmcode-Mitteln, urn alle Schritte von jedem 
beliebigen der Anspriiche 1 bis 9 durchzufuhren, wenn das Programm auf einem 
Computer ausgefuhrt wird. 

16. Computerprogrammprodukt mit Programmcodemitteln, die auf einem 
computerlesbaren Datentrager gespeichert sind, um das Verfahren nach jedem 
beliebigen der Anspriiche 1 bis 9 durchzufuhren, wenn das Programmprodukt auf 
einem Computer ausgefuhrt wird. 
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Verfahren und Vorrichtung fUr einen fahrzeughezpgenen Telematikdienst 
Zusammenfassung 

Es werden ein Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 
vorgeschlagen, bei welchem der Telematikdienst in Teilfunktionalitaten untergliedert ist 
und diese Teilfunktionalitaten auf Server und Endgerat aufgeteilt sind. 



(Figur2) 




He 



^1 



31* 



(i, 2o2?62 



TLL 



2Z 



so. 



— - 


- "fl 




" 


















. *- 



id' 



S3 



S4o 



U4 




S<2o 



X S24 



iz<r 



~S.Z-S' 



ill 



